Companies and other organizations sometimes use structured document formats to storage large amounts of information. Structured document formats can include open (or semi-open) formats like XML (extensible markup language), JSON (JavaScript Object Notation), and comma separate values (CSV) and proprietary formats like Microsoft Excel. The types of information and the format used by organizations can vary widely—sometimes even within an individual organization. For example, an XML file may hold a list of employees for an organization, a JSON file may hold a list of employee reviews, an Excel file may hold a list of the projects that are being implemented and those that are planned (along with the team members for each project), a CSV file may hold the names of employees that are attending the companies summer party, etc. . . . . Further numbers of files (e.g., tens or even hundreds of other files) may also hold additional (and sometimes duplicative data).
In such an environment it will be appreciated that the overall complexity of how the data is stored may be very complex—so complex that changes to one file may cause a cascade of problems for other files. This complexity can further increase (e.g., exponentially) as the number of changes and/or the number of elements that are affected by a given change also increases. When these files are stored in-memory (e.g., RAM) of a computer system a model of the file and/or the data that is represented in that file may be created. For example, when an XML file is loaded a document object model (DOM) may be created and stored in RAM. The DOM presents the XML file as a tree structure that can be programmatically manipulated.
As downside of current techniques for handling structure document formats like XML and JSON is that there is limited ability to handle changes to the in-memory model representation. For example, existing XML parsing techniques that rely on the document object model (DOM) or Simple API for XML (SAX) do not provide out of the box functionality for registering events with callbacks. Instead, these techniques are mainly used for parsing the XML model, but lack support for custom event handling.
While SAX does include events like: NotIdentifiableEvent, ParseConversionEvent, PrintConversionEvent, ValidationEvent, they are of limited help in handling changes throughout a model. A SAX parser can be used to parse a model represented in XML and existing functions like startElement( ) or stopElement( ) can be overridden in the default Handlers. But with this approach, it is still not possible to perform bulk and/or lazy custom event handling on the XML model. Instead, the SAX parser determines when to register and perform an event. Accordingly, a process can only perform actions while a model is being parsed—not when a change is made to an element in the model. This approach means that there is no functionality for parsing the XML model for change events or functionality for performing even callbacks to interested observers.
For JSON based models, existing parsing techniques like Jackson or GSON may only allow Object mappers which convert the JSON files to and from Java objects, but these are only useful for parsing the JSON files and there is no OOTB functionality supports event handling for the JSON-based models.
Certain example embodiments address the above and/or other concerns. For example, certain example embodiments provide for a unified handling of model changes in bulk. In certain examples, callbacks are provided to handle the impact of changes that may occur across different elements of a model (or multiple different models). In certain instances, a callback for an event may be handled by a custom Observer handlers. In certain examples, the process described herein may call an Observer handler once an event is triggered. Certain techniques described herein may provide flexible event handling (e.g., via custom handlers), scalable event handling (e.g., so that changes may be handled across a model or different models), and/or a declarative approach for event handling. The techniques herein may be used to handle changes to models that are persisted in different formats such as, for example, XML, JSON, and the like.
In certain example embodiments, a computer system comprising a non-volatile storage system and a processing system that includes at least one hardware processor that is coupled to electronic memory is provided. The non-volatile storage system is configured to store at least one file that includes data elements in a structured file format and at least one configuration file that includes programmatic definitions for observer and/or observable handlers. The processing system is configured to (e.g., programmed to via computer executable code) generate at least one in-memory model of the at least one file by loading the at least one file stored in the non-volatile storage system to the electronic memory that is coupled to the at least one hardware processor and create at least one list of observer objects by determining, from among the data elements of the at least one in-memory model, that at least one of the data elements, or a property thereof, is annotated as an observer. The processing system is further configured to create at least one list of observable objects by determining, from among the data elements of the at least one in-memory model, that at least one of the data elements, or a property thereof, is annotated as observable, where each one of the observable elements shares an attribute with at least one of the observer elements. For each one of the created observer and observable objects, the processing system generates a handler object and links the handler object to the corresponding created observer or observable object. A determination is made that a data value of a first observable element of the at least one in-memory model is to be updated and responsive to this determination the customer handlers are invoked. Specifically, the processing system is configured to invoke a first generated handler for the first observable object and invoke a second generated handler for an observer object that shares the same attribute with the first observable object, where the first and second generated handlers cause an update to a data value in the at least one in-memory model. Upon determination that the data value has been successfully updated, the in-memory model that was updated is then persisted to a file on the non-volatile storage medium.
In certain example embodiments, the at least one file includes a plurality of files (e.g., such that multiple files are processed), where multiple different structured file formats are used among the plurality of files and each file is associated with a corresponding in-memory model.
In certain examples embodiments, at least one of the observable elements and at least one over the observer elements are associated with data from different files and/or different in-memory models.
In certain examples embodiments, the multiple different structured file formats includes Extensible Markup Language (XML) and JavaScript Object Notation (JSON) file formats.
In certain examples embodiments, the observer object that shares the same attribute with the first observable object is a plurality of observer object that share the same attribute with the first observable object, where each one of the plurality of observer objects invokes (e.g., is tied to invocation of) a corresponding generated handler.
In certain examples embodiments, the processing system is further configured to maintain a master store of observable objects and observer objects and for each for each observable object that has been generated for a new in-memory model, generate a first list of observer objects from the master store of observer objects that each share the same attribute for the corresponding observable object associated with the new in-memory model. The list of observer objects is then added to the observer objects associated with the new in-memory model.
In certain examples embodiments, the processing system is further configured to for each observable object in the master store, generate a second list of observer objects associated with the new in-memory model that share the same attribute for the corresponding observable object from the master store. The second list of observer objects is then added to the master store of observer objects.
In certain examples embodiments, the processing system is further configured to add observer objects and observable objects associated with the new in-memory model to, respectively, the master store of observer objects and observable objects.
In certain examples embodiments, determination that the at least one of the data elements is annotated as an observer or observable is based on determining that data element is annotated during the loading of the at least one file.
Certain example embodiments provide for a multi-subscribe technique where a model element can be observable for multiple topics and observer for multiple topics. For example, in a products inventory application the quantity of a product depends on the sale of that product and any if the product is sold. In this example, the product quantity may be tagged as observer for topics like change in the purchase quantity of the product and the product quantity in the procurement order.
Certain example embodiments provide for a flexible configuration. In certain examples, configurable event and change (observer) handlers are stored into an external configuration file. Thus the specifics of the event handlers which perform actions on an element of a model and change handlers that handle the change at the observers are externalized to a configuration file.
Certain example embodiments provide multi-model support where change in a model can be notified to the observers in multiple models using a merging functionality. Such functionality may be advantageous when there are multiple types of models which are dependent on each other. For example, in a cost management application, consider that there is a PriceIndex.xml file and Prodcutsjson file. The PriceIndex.xml may contain factors which influence the profitability of a company like the “ProfitIndex”, and the Products.json may contain the data about each product like Name, Price, etc. . . . . Accordingly, if a change in the ProfitIndex in the PriceIndex.xml may be propagated to change the prices of all the Products in the Products.json file.
Certain example embodiments provide a declarative framework where observable elements and observer elements are identified by just tagging them with topics. For example, declarations of observable or observer may be used like the following example, @Observable(topics={“priceIndex”}) @Observer(topics={“priceIndex”}).
Corresponding methods and non-transitory computer readable storage mediums tangibly storing instructions for performing such methods also are provided by certain example embodiments, as are corresponding computer programs.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.